AWS ECS Fargate 환경에서 스케일 아웃을 아무리 잘해봐도 NestJS 컨테이너가 뜨는데 최소 7분은 걸린다.
오토스케일링은 한박자 느리게 동작해서 이미 서버가 다 터진 후에야 스케일 아웃 되는 일이 허다하다.
도메인 특성에 따라 다르겠지만, 이걸 사전에 완벽하게 파악하고 서버를 알맞은 갯수로 증설시키는게 정녕 가능할까? 나는 절대 불가능하다고 본다.
애초에 서버 1대가 처리할 수 있는 트래픽 량을 정의하는 것 자체가 가능할까? 어떤 요청이냐에 따라서 서버에 가해지는 부하량이 다를텐데 성급한 일반화를 바탕으로 잘못된 예측을 하는게 더 위험한거 아닐까?
이 문제는 과다 프로비저닝을 유도하게 되고 결국 서버비가 겉잡을 수 없이 커지는 결과로 이어지게 된다. (그렇다고 완벽하게 트래픽 증가분을 처리하기를 기대하긴 힘들다)
이 얼마나 끔찍한 상황인가?
CPU 집약적인 처리를 하는 서버가 아니라,
일반적인 웹 서버 어플리케이션 정도라면 서버리스를 써보는게 어떨까.
요즘 Cloud Service Provider들은 너도나도 앞다퉈서 서버리스 환경을 주력으로 밀고 있다.
AWS Lambda, Cloudflare Workers, GCP Functions, OCI Functions 등등
잉여 자원들을 모아 더욱 효율적으로 사용할 수 있고, EC2 같이 정적으로 빌려줄때 가격보다 훨씬 비싼 가격을 책정할 수 있기 때문에 새로운 수익 모델로써 인기가 있는 모양이다.
소비자 입장에서 바라봤을때는 어떨까?
보통 프리티어나 최소 요금제에 포함되어있는 기본 할당량이 넉넉해서 많이 사용하지 않는다면 과금 걱정을 딱히 안해도 되고,
추가 과금도 CPU 집약적 처리 + 오랜 시간동안 돌아가는 함수가 아니라면 크게 걱정 안해도 되고,
서비스가 대박이 났을때 서버 죽을 걱정 안해도 된다.
경험상 총 비용만 놓고 비교했을때 서버리스로 만드는 편이 많게는 10배 정도 더 저렴했다.
얻는게 있으면 잃는게 있다.
서버리스 특성상 다양한 단점이 있는데, 내가 느낀건 크게 다음과 같다.
콜드 스타트 문제는 정신 승리를 했다.
늘어나는 트래픽들의 첫 요청에 대해서만 추가 지연이 생기는 것이기도 하고,
경험상 최적화를 잘 해놓으면 많아봤자 500ms 정도 밖에 안늘어나기 때문에 고객 입장에서 봤을때 크게 답답한 점은 없을 것이다.
Go 같은 언어를 사용하면 훨씬 더 빨라지리라.
오토스케일링 7분이 0.5초로 줄었다고 생각하니 마음이 편해졌다.
서버가 죽어버리는 것보다야 조금 느려지는게 낫지 암.
Cloud Service Provider에 대한 의존성 문제는 Serverless Framework 같은 도구를 사용하면 비교적 쉽게 우회를 할 수 있는데,
Serverless Framework가 v4 버전부터 유료화 선언 + 라이센스 변경 + AWS 한정 지원이 되면서 커뮤니티가 난리가 났다.
나도 이 변경사항을 봤을때 당시에는 얼척이 없었다.
이제는 각 Cloud Service Provider에서 제공하는 배포 도구를 사용하는 수 밖에 없을 것 같은데,
Hono 같은 라이브러리를 사용하면 다른 Cloud Service Provider로 갈아타는게 보다 용이해지니까
CI/CD 수정하는거 외엔 크게 작업할게 없어서 심각한 문제는 아닌 것 같다.
애초에 의존성 문제가 있는게 나쁜걸까 싶다.
대부분의 기업들이 AWS에 강한 의존성을 가지고 있지 않나..
DB Connection Pool 관리는 AWS RDS Proxy 같은 서비스를 사용하면 된다.
아니면 서버리스 함수들이 동시에 돌아가는 최대량 만큼 사전에 DB Connection 여유를 할당해두면 된다.
1개 함수 = 1개 요청 구조이기 때문에
특정 부하 요청이 서버 전반에 영향을 끼치지 않기 때문에 병목 지점을 찾아내는게 훨씬 간단하고 쉽다.
Hono에 Timing 같은 기능을 이용하면 좋다.
서버리스 DB는 안써봐서 아직 잘 모르겠다.
싸고, 배포 매우매우매우 빠르고, 부하 걱정 안해도 되고, 구조가 단순하고 …
서버리스 기술이 대중화되면 DevOps의 입지가 난감해질 것 같다.
결론 = I Love Cloudflare Workers.